-
Notifications
You must be signed in to change notification settings - Fork 760
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve toolchain and environment missing error messages #4596
Conversation
c45acd8
to
8e56c42
Compare
#[derive(Clone, Debug, Error)] | ||
pub enum ToolchainNotFound { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The enum is now a struct which contains the ToolchainRequest
instead of de-structuring the request here.
/// The requested directory path does not exist. | ||
DirectoryNotFound(PathBuf), | ||
/// No Python executables could be found in the requested directory. | ||
ExecutableNotFoundInDirectory(PathBuf, PathBuf), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We lose the ability to distinguish between these cases in error messages, but I don't think it's particularly critical.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By "these cases", do you mean file vs. directory vs. executable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specifically whether its a missing directory or a missing executable in the directory. We'll always raise the latter now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would also be harder to encode things like "this exists but is not an executable" in the future. In practice, I don't think we were even using the variant right now.
24c9f0d
to
1e84c62
Compare
1e84c62
to
d78ba43
Compare
d78ba43
to
6183da7
Compare
crates/uv/tests/venv.rs
Outdated
@@ -264,7 +264,7 @@ fn create_venv_unknown_python_minor() { | |||
----- stdout ----- | |||
|
|||
----- stderr ----- | |||
× No interpreter found for Python 3.100 in system toolchains | |||
× No toolchain found for Python 3.100 in system path or `py` launcher |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are your thoughts on "toolchain" as user-facing copy vs. interpreter? I feel like interpreter is more familiar to folks but seeing that you proactively changed it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure, but I'd like to be consistent. We're going to talk about managed toolchains a lot going forward so I think we might want to move in that direction.
A nuance is that we look for an interpreter in order to discover a toolchain. I guess that leans towards using "interpreter" here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I weakly prefer interpreter I think. It seems likely to land better with Python users. But the inconsistency with using "toolchain" in written docs does seem unfortunate. How crazy would it be to switch to "interpreter" everywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well.. I talked about that in the initial design and @konstin did clarify that there's much more than the interpreter involved e.g. the managed toolchains include the standard library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this change, I'll use "interpreter" because I want to get these changes out asap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yeah I hear ya. If y'all already dug into the naming here then I defer to you. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have yet to be convinced that "toolchain" is the best user-facing concept :) we should all chat more.
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { | ||
let sources = match self.environment_preference { | ||
EnvironmentPreference::Any => { | ||
format!("virtual environments or {}", self.toolchain_preference) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this be "virtual environments or managed or system toolchains"? I feel like it should be Oxford comma'd but I know that's tedious...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😬 I know right. I considered doing an extra match to fix this.... but I didn't have it in me. Think it's worth it? I might want to construct a test covering this so I know it matters if I do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the basic idea here is that rather than creating a ToolchainNotFound
variant, we base the error message on the request itself? Makes sense to me.
What ToolchainRequest
was being returned such that I saw that "error: No Python interpreters found in system toolchains" message in my ruff-lsp
PR?
Yep, though that kind of just fell out of me making some other changes to actually propagate the information for correct error messages.
This was because the |
crates/uv/tests/venv.rs
Outdated
@@ -264,7 +264,7 @@ fn create_venv_unknown_python_minor() { | |||
----- stdout ----- | |||
|
|||
----- stderr ----- | |||
× No interpreter found for Python 3.100 in system toolchains | |||
× No toolchain found for Python 3.100 in system path or `py` launcher |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I weakly prefer interpreter I think. It seems likely to land better with Python users. But the inconsistency with using "toolchain" in written docs does seem unfortunate. How crazy would it be to switch to "interpreter" everywhere?
6183da7
to
b1893d9
Compare
b1893d9
to
42479bd
Compare
The journey here can be seen in:
I collapsed all the commits here because only the last one in the stack got us to a "correct" error message.
There are a few architectural changes:
MissingEnvironment
andEnvironmentNotFound
type forPythonEnvironment::find
allowing different error messages when searching for environmentsToolchainNotFound
becomes a struct with theToolchainRequest
which greatly simplifies missing toolchain error formattingToolchainNotFound
tracks theEnvironmentPreference
so it can accurately report the locations checkedThe messages look like this now, instead of the bland (and often incorrect): "No Python interpreter found in system toolchains".
I'd like to follow this with hints, suggesting creating an environment or using system in some cases.